Off-platform data storage is a service frequently used by an application running on a computing platform. With modern networked computer systems, off-platform data storage does not exist in an isolated environment along with the platform it serves; instead the platform and storage are linked through a network. Indeed, in general a network-connected storage system will provide off-platform data storage for multiple computing platforms.
In a storage area network (SAN) multiple storage devices provide off-platform data storage for multiple computing platforms. SANs meet a number of IT managers' needs in that they provide a flexible and manageable storage infrastructure. They are designed to support hundreds to thousands of devices providing high performance, backup, and high availability and as such provide a powerful storage infrastructure for business critical functions. This means that SAN systems will hold large amounts of business critical data which in turn implies some severe security requirements. There is also a trend of relying on contractors, outsourced system management and even hosting systems in third party data centres which all combine to mean great care should be taken with protecting data against internal and external attacks as well as accidental leaks.
SAN networks connect every computer (server) to every storage device bringing obvious security concerns. Each server is configured to talk to particular disks with in the SAN system. Typically, fabric level security is used to divide disks into zones or uses LUNs on large RAID systems and the SAN switching fabric is then relied upon to separate these zones. This can be done either using soft zoning (based on a name server) or hard zoning in the switches. Security can also be provided at the storage device level where machines have to be granted access to each storage device. These security techniques provide a broad segregation of data at the device level stopping unauthorised access to the data. However, such techniques are by themselves inadequate for several reasons: firstly, the administrators can reconfigure the SAN system such that a malicious insider could add an extra machine to gain unauthorised data access; secondly, the data is not encrypted over the network connection between the disks and servers which opens up possibilities of data leaking or being inserted; thirdly, the data remains unencrypted on the disks within a data centre, and on associated backups leaving potential for leakage.
One solution to these problems is disclosed in the paper “Encryption and key management in a SAN”, A. Baldwin and S. Shiu, SISW '02: Proceedings of the First International IEEE Security in Storage Workshop, page 35, Washington, D.C., USA, (2002)IEEE Computer Society. This paper describes how encryption and a strong key management scheme can help tighten security in a SAN system. The approach adopted in the paper is illustrated in FIG. 9 of the accompanying drawings. FIG. 9 shows a SAN in which servers 90 are connected through the SAN fabric 91 (including a switch 92) to a storage pool 93 made up of a plurality of storage devices. Each server 90 is provided with a secure hardware bus adaptor (SHBA) 94 which is provided with a respective encryption/decryption key from a key manager 95. Data to be stored by a server 90 to the storage pool 93 is encrypted by the associated SHBA 94 before being transferred over the network; the data is thus transferred and stored in encrypted form and when retrieved to the server 90, the encrypted data is decrypted by the SHBA 94.
The foregoing arrangement works well for the case of each server being dedicated to one specific user; however, modern data centers are, for reasons of efficiency and flexibility, virtualized environments. A virtualized data centre is a data centre that uses virtualization mechanism to share resources (computing platforms, storage etc.) between its many customers.
FIG. 10 of the accompanying drawings illustrates the typical configuration of a virtualized data centre providing data storage. On the right-hand side of the Figure, virtualization is used on each server (physical computing platform) 100 to create a number of Virtual Machines (VM1 to VMi) each running in its own domain on top of a virtual machine monitor VMM (a.k.a. ‘hypervisor’) 101 that ensures isolation of the domains. Each VM runs its own separate guest operating system and is under the illusion that it is the only machine using the hardware resources of the system. In fact, the guest operating system of each VM cannot access the physical resources directly but only through the privileged management domain ‘DOM-0’ 102 (domain number zero) with which it can interact through the Virtual Machine Monitor (VMM).
The customers of the data centre hire the virtual machines and connect to them using virtual private networks (VPN) in order to use the facilities provided by the data centre. In the present illustrated example, an iSCSI storage resource 104 is accessible to the VMs via an iSCSI initiator 103 run in DOM-0. The storage resource 104 (here shown as an array of disks 1 to n) is also virtualized, thereby providing virtual disks (VDisks 1 to m), which are mapped to the physical disks. Virtual disks are then assigned to individual virtual machines. Each virtual machine sees a virtual block device which appears to it as a local disk. This is mapped to a device driver (iScsi initiator 103) within Dom0 which interacts with the iScsi storage resource 104 providing the virtual disk.
A Utility Management System (UMS) 107 is responsible for setting up the virtual resources requested by customers. For example, for a specified client, the UMS 107 might ask iSCSI storage resource 104 to create a virtual disk and once a disk has been created, it requests a physical host to set up a virtual machine for using the newly created virtual disk. Since the data stored on iSCSI storage target is not encrypted, not only the owner of the data but also other entities, for example administrator of iSCSI storage target or an eavesdropper, can read the actual contents of the stored data.
For secure storage in a virtualized data centre, the data sent to the storage resource 104 should be encrypted. However, the solution discussed above of using a respective secure hardware bus adaptor for each machine is not practical when extended into a virtualized environment as it would require a respective secure hardware bus adaptor for each potential virtual machine. Furthermore, an alternative approach of providing for encryption/decryption in each virtual domain makes the keys used (and therefore the encrypted data) vulnerable to security weaknesses in the guest operating system and applications running in the domain. Indeed, encryption-based data security in a virtualized data centre relies on having key management solutions that are at least as strong as the other parts of the virtualized data center.
The last decade has seen the emergence of trusted computing platforms based a trusted secure hardware device known as a Trusted Platform Module (TPM). For virtualized environments, the hardware TPM may be supplemented by one or more software (a.k.a. virtual) TPMs. A description of trusted computing principles, of a TPM, and of example trusted platforms is given in the Appendix hereto with reference to FIGS. 1 to 8 of the accompanying drawings.
A TPM incorporates cryptographic functionality; however, this functionality is specific to the role of the TPM in providing reliable integrity metrics of the associated computing platform. The cryptographic functionality of a TPM is not intended to provide bulk cryptographic services, such as encryption/decryption of data, to an application running on the platform.
An object of the present invention is to provide trusted key management in a virtualized system to facilitate the provision of cryptographic-based services such as secure networking and storage.